EuroCD 3/EuroCD 3.iso/Communication/Citadel_BBS/Docs/Cit_Amiga_Docs.lha/citadel.doc

Text File | 1995-01-14 | 48KB | 989 lines

Document Citadel.Guide
@REMARK : Citadel.guide 1.0 (27.11.94)
1. MAIN

      The documentation  contained  is  a  collection  of  information
 based  on  the  original  Citadel  86  documentation by Hue, JR.  The
 mistakes are mine.

      It is  pretty much a complete reference manual and every attempt
 is  being  made  to  make  this  a  complete  manual with all details
 explained  so  that  even the most novice of users can understand how
 to  setup  and  run  a bbs.  The most important thing is to read this
 documentation and give it a try!
2. Citadel History

      What is  Citadel?  Citadel  is  a Freeware project.  The source,
 executables  and  all  the documentation are available for no cost to
 you.  If you paid for this, someone is ripping you off.

      Citadel was  written in mid-December 1981 by CrT.  Miraculously,
 it  ran  three  days  unattended  over  New  Year's,  collecting some
 remarkably  favorable  reactions.   During  the months that it ran at
 633-3282  (ODD-DATA),  Citadel  became one of the more popular BBs in
 town,  and  there  was  some  disappointment  when a hardware failure
 forced  the  system down in February of 1982.  But in January CrT had
 published  the  source  code  in  BDS  C,  putting  it  in the public
 domain.

      David Mitchell  brought  up  the next incarnation of the Citadel
 program  in  April  of  1982, running on hardware provided by Richard
 Knox.   Called  the  Island  Communication  System,  it is located on
 Bainbridge  Island  in  Puget  Sound.  ICS has about 30 regular users
 and  about  120  log  entries.   Newcomers find it easy to learn, and
 often  leave  messages praising it.  Some of the system's daily users
 are in Boston.

      Citadel is   descended   from   DandD.pas,   an  adventure  game
 editor/driver.   It  is  arranged as a series of rooms, starting with
 the  LOBBY.   In  each  room  the user can read existing messages and
 leave  more.   The  system  was  brought  up  with only one room, the
 LOBBY.   Additional  rooms were created by the users, with room names
 appropriate to the topics covered.

      Environment:  Citadel  has  had  a checkered past.  It first ran
 on  a  64K  Heath  H89  with Magnolia CP/M, Hayes Smartmodem (plus an
 acoustic on another port) and BDS C V1.32.

      As time  went  on,  Citadel  was ported to the Amiga, Atari, and
 even  the  MAC.   Citadel runs on many platforms and since the source
 is available will probably run on most future ones too.
3. What is Citadel-68K

      Citadel-68K(also know  as  Amiga  Citadel)  is a single user BBS
 program.   It is a direct decendant of the 3.42 Citadel 86 by Hue, JR
 in Minnesota.

      Citadel comes  in  two  flavors, a 68000 based version that will
 run  on  any  Amiga and an optimized 68030 based.  Citadel is able to
 run  on any Amiga model and under any OS from 1.2 to the latest.  The
 CTDL(main  BBS  executable) and CONFG(BBS configuration tool) come in
 the  two  forms,  the  utilities come in the 68000 version only.  The
 Amiga  Citadel  is  a  direct port from the IBM Citadel 86 by Hue Jr.
 It  originally was done by Jay Johnston, who did not have the time to
 continue  it  so  I, Tony Preston now maintain it.   I don't have the
 time either, but I try...
3.1. Support Systems

      Probably the  hardest  part  of  running  a  Citadel  is getting
 started.   Citadel is not the most common of BBS programs even though
 it is free.

      You should  be  able  to  read  this  document  and  setup  your
 configuration  file,  run  `CONFG'  and  then startup the BBS with no
 problems.   Since  this rarely happens and having a helping hand from
 someone  that  has  already  done  what you are trying to do can make
 things  easier,  you  might want to try one of these three places for
 help and information.

      The first  is  The  Amiga  Zone,  my  BBS(609-953-8159).   It is
 available  24  hours  and is where you will find the most support and
 help.   I  will  often  chat with people that call for help and alway
 try  to  answer  mail messages promptly.  Since calling long distance
 may  not  be  an option for you, check around in your area and see if
 you  can  find  a local Citadel where you can take major advantage of
 the  networking  features  built into Citadel!  The `C86Net' contains
 several  support  rooms where you can post your questions and usually
 get  quick  answers.  These rooms are "Citadel 68K" and "Sysop Only".
 If  your  local sysop will let you have some Long Distance credit you
 can  send  me  domain  mail at "tony preston@The Amiga Zone.NJ".  You
 will  learn  more  about  domain mail later.  There are many Citadels
 active  on  the network so you might check the `BBS List' included in
 this  document  to see if one is local to you.  finally, you can send
 me  mail  via   Internet.  I will answer the mail quickly monday thru
 friday.   Anything  sent over the weekend will wait till monday.  you
 can       reach       me       at      "[e-mail]"      or
 "[e-mail]".
3.2. Hardware required

      The minimum  configuration  for `Citadel' is a 512K Amiga with 2
 floppies.   This will allow you to run the BBS, but probably not much
 more.   There  are  some people that have run Citadel on such a small
 system.   Most either expand their system or just quit running it.  1
 MB  of memory and a hard drive is really the practical limit.  I have
 created  and  ran  a  test  bbs  on an A500 with 1 MB of memory and 2
 floppies.   I  would recommend that you have 2 MBs and as a minimum a
 20 MB HD for the BBS.
3.3. Requirements

      Citadel will  run  on  any  Amiga  Model.   There are some minor
 problems  with running CONFG and fast memory on A3000s and A4000, but
 the  work  around  is  simply  to run NOFastMem before running CONFG.
 These  may  be fixed at any time, but since I do not have an A3000 or
 A4000, I can't look for the problem.

      Citadel does  not need any external support software to run.  It
 relies  on  the Operating System for 100% of the normal functions and
 is compatible with 1.2 through to the latest OS.

      Citadel does  not use alot of stack space, but will require that
 you  have your stack set to 8K or larger.  8K is more than enough for
 even  the  largest  and most complex Citadel.  Citadel will make sure
 you  have  at  least  an  8K  stack  or  it will quit with a `Citadel
 Error'.

      It is  important  to note is that you really should plan on a 24
 hour  BBs, with a dedicated phone line.  A BBS that is available from
 11pm  to  6am  is not going to be very popular.  I would suggest that
 you  do  not even consider networking unless your BBS is on a regular
 schedule.
3.4. Citadel Error

      Citadel is  a  complex  system  of  functions.   In  any complex
 system,  things  go  wrong.  Citadel attempts to validate most things
 when it starts up.

      Once you  have the BBS up and running, you still may run into an
 occasional  problem.   The first thing to do is to collect sufficient
 information  on what exactly is going on.  Many times, if you look at
 the data you might be able to solve the problem youself!

      In general,  if  you  get an error and this information does not
 tell  you  how to correct it, collect as much information as possible
 and  report  what  happended  either directly to me or in the Citadel
 68k  room.   The first thing to look for is a file called `debug.sys'
 or  `crash.sys'.   These  files  should  appear  in either your audit
 area,  the  home  area,  or  the  location you started up Citadel.  I
 usually  will  want the information in these files(even if it is just
 a  cryptic  one  line  message  like  "dependant variables mismatch",
 sometimes  it  tells  me  exactly  where the problem is).  The second
 thing  I  will  tell  you  to  do is turn on debug, Here is a general
 method I end up telling people:

           1) go  into  the Sysop menu, turn on debug "D" option.  You
      can also do this by typing ^D in the console window.

           2) Shut down your Citadel, "X" option.

           3) delete  debug.sys  in  the  audit  area(or save it if it
      contains  info  I  might  need.  At the least, edit the file and
      add  some  markers  (like  two lines of asterisks) at the end of
      the file.

           4) Bring  up  Citadel and attempt to reproduce the problem.
      If  you  cannot  do it locally, you might even ask a remote user
      to  do  it  for  you.  leave debug on.  Note:  If you run confg,
      debug  is  automatically  turned  off, repeat the above steps to
      turn it on again.

           5) archive  all  the  information(using something like lha)
      and  arrange  to get the information to me.  I may call your BBS
      to  download  the  file so make some arrangements in Citadel 68K
      so I know where it is.

      The above  may  generate  alot of output.  Much of the output is
 cryptic  and may not seem like anything understandable.  It is mostly
 internal data and is useful to me.

      From time   to  time,  other  errors  may  appear  when  you  do
 something  that  you  really  should not do(like power down the modem
 and then power it up).  These will generate errors like:

           Error:  [1]IOError = nnnn

           Error:  [2]IOError = nnnn

                Reason:  nnnn  is a result code returned from a serial
           port  i/o,  usually  a  dropped carrier(small timing window
           for  a  race  condition  could  cause  this).  The error is
           handled  for  99%  of  the  cases  in a way that will cause
           Citadel  to  recover  and  reset.   [1] is the case where I
           check  to see what is in the serial port buffer, and [2] is
           when the actual read is done.

           Error:   Startup Error Code nn

                Reason:  something    went    wrong    during   system
           initialization. The reasons are:

                     1 -  unable  to  open intuition.library, you must
                be 1.2 or greater to run Citadel.

                     2 -  unable  to open graphics.library, same as 1.
                This  error also used to mean that the req.library was
                not  in  the  libs:  directory.   This  is no longer a
                requirement.    Citadel   does   not   depend  on  the
                req.library(versions 3.42.P15 or later anyway).

                     3 -  Insufficient  Stack  space, Citadel versions
                3.42.E19  and  earlier  required  a  large stack, much
                larger  than  needed  (50K).   Versions  3.42.P35  and
                later  will  require  a  8K  stack  or less(I am still
                adjusting  the  values  down).  Citadel still requires
                the larger limit just to be cautious.

                     11 -  Console  Open Error.  Catch all for console
                window  errors If you are using #WBSCREEN, try without
                it.

                     25 -  Open  Serial  Port  Failed,  Well,  Citadel
                could  not get to the serial port(maybe something else
                has  it  open.   Note:  You will not get this error if
                you  run  Citadel while it is already running since it
                opens the serial port in a shared mode.

                     31 -   Could   not   create   a  Port  for  timer
                communications,  Low  memory?   Trashed system tables?
                Try  a  re-boot.   This  is  one of those, "you should
                never  get  here".   If  you  bug me with this type of
                problem,   you   had   better   have   a  full  system
                configuration and alot of details.

                     32 - could not create an I/O request. See 31.

                     33 - Open timer.device failed.  See 31.

                Note:  In  the  serial  port  open errors, and in most
           cases  with  debug  turned  on,  you  will get a text error
           message of the form:

                1:    Date - Dos Error:nnnn

                2:    (some text as to what happened)

                3:    (some  text as to what happened) <-- you may get
           only one line.

                4:    Reason: <error text>

                5:    Current Directory


                Line 1:  is the internal error code(less than 100), or
           the Dos error code.

                Lines 2-3:  will  either  be  a  command(like  in  the
           external  protocols)  and  a text line, or just one line of
           text.    External   commands  will  display  the  text  and
           command, most errors do not have an external command.

                4: is  the  reason  the  error  occured(from  the Exec
           routine Fault).

                5: is  the  current  directory.   This is important if
           you  are  trying  to  setup  a  door for example and in the
           wrong directory.

                If the  problem  is  reproducable, do it several times
           and   record  all  possible  information,  especially  your
           system  configuration!  If it happens just once and you can
           not  reproduce  it,  then  still record what you can, check
           things like memory in use, what is running.

           Note:  If  you  have  a problem that seems to happen often,
      realize  that  I  rarely  have a crash.  Pleae check to see that
      something  else is not causing the problem.  Remove commodities,
      other  programs  and  see  if  you can cause the problem without
      that  super-duper-whiz-bang  mouse  accelerator/screen  blanker!
      It  probably  ain't  Citadel!   If  you  are  running  on a 512K
      system,  you  may  just  be  running out of memory.  While every
      attempt  has  been  made  to  exit  in  a  friendly  manner,  no
      guarentees...
3.5. Limits
 For  the  most  part,`Citadel'  only  has  your  imagination  as  the
 limits...   In  practicality, there are some real physical limits you
 will  have.  Each of these limits can be difficult to adjust later so
 some  planning  is  important at this point.  You must set a limit on
 the  number  of users (`#LOGSIZE'), rooms (`#MAXROOMS'), and messages
 (`#MESSAGEK').   These  parameters will directly determine the amount
 of  memory used while the BBS is running and the disk space needed to
 support the message base and userlog.
4. CONFG

      To setup  the  BBS,  you must first configure your system.  This
 means  taking  the  example  configuration  and  tayloring it to your
 liking.   The  example  is  based  directly on `The Amiga Zone'.  The
 first  thing  you must do is chose a name for your BBS (`#NODENAME'),
 a  default  banner  (see  `banners'  and `#NODETITLE'), enter in your
 Identification  (`#NODEID').  It is this basic information that users
 and  other  Citadels will know your bbs by.  Once you have an idea of
 what  the  theme of your BBS is, you can apply it to the initial room
 (`#BASEROOM'),  and  floor (`#MAINFLOOR').  These will be the initial
 place  that  people  are located at when they login to your BBS.  Now
 comes  the real work.  You must decide some `basic system parameters'
 that  will  define how much disk space your system will use.  This is
 important  since  the  smaller  the  message  base  is,  the  quicker
 messages  will  scroll off.  Citadel has a fixed message base so that
 once  you  configure  your  system, the disk space usage is constant.
 You  will  never  run  out  of  message space, the BBS will reuse the
 existing  space deleting the oldest messages to make room for the new
 ones.

      Next we  have  the  `USERPARAMETERS'  which  define  the default
 `PRIVILEGES'  for  your  users.  These determine how open your system
 is(can  a  user  create their own account or do you do it?).  Whether
 people  are  able  to use doors, or post messages to the network.  If
 you  restrict  people,  then  they  will  have  to  ask  you  for the
 privilege(and  you will have to give it to those you choose).  If you
 make  them  the default, people will get them automatically, you then
 do  not have to do anything.  I setup my system to be as automatic as
 possible.   People can create their own account and do not need to be
 validated.   The  example  setup  is  configured  that way.  The most
 important  user  is  the  SYSOP, You.  There are some parameters that
 make  your  life  easier.  the  `sysopparameters'  will  take care of
 those.   Now  we  get  to  `Network'  parameters  which  you can skip
 initially,  but  will  eventually want to look into.  Get your BBS up
 and running first before you worry about that.

      The basic  BBS has several `areas' you will want to setup.  Most
 people  will  setup  a logical assignment that is the root of the BBS
 disk  area  (called  `#HOMEAREA')  and make everything a subdirectory
 off  of that.  Citadel is pretty flexible, if you are running from an
 A500 with 2 floppies, it will run, even if the size will be small!

      CONFG is   simple   to   run.    Once   you   have  created  the
 `CTDLCNFG.SYS'  file,  you  just run CONFG in the same directory.  It
 will  read each line, and report any errors.  If there are errors, it
 will  stop after the last line is read.  If no errors, it will finish
 up  its  processing,  possibly  ask you some questions and create all
 the required files.
4.1. SYSOPPARAMETERS

4.2. USERPARAMETERS

      User parameters  is  a  catch  all  for  most  of the parameters
 related  to  user.   Since  the BBS is about users, nearly everything
 could   be   put  into  this  catagory.   There  are  three  sets  of
 parameters.   The  first is the `unlogged users' parameters.  This is
 all  the  parameters  relating  to a user that has not logged in yet.
 The  second  is the `PRIVILEGES', the values given to a new user when
 their account is created.  The last is the `user characteristics'.

      Each of  these  parameters must be setup and will define the way
 your BBS operates.
4.3. unlogged users

      When a  user first calls the BBS, they will get a set of default
 parameters  that will define how the BBS operates until they login or
 create  an account.  If you do not allow them to create an account on
 their  own,  they  will have to send you mail and you will have to do
 this  manually(called  account  validation).   Citadel  allows you to
 operate either way.  For unlogged users, the parameters are:

      `#UNLOGGED-WIDTH'   -  The default width of a line

      `#LOGINOK'          -  Open/Close system control

      `#ENTEROK'          -  Can users enter messages while not logged in?

      `#READOK'           -  Can users read messages while not logged in?

      `#ANON-MAIL-LENGTH' -  Limit on anonymous mail length to prevent `RUGGIES'

      `#LOGIN-ATTEMPTS'   -  Limit on how many times a user can make a mistake
4.4. PRIVILEGES

      This section  defines  the  user  privileges,  defaults  and all
 related  parameters.   These  parameters  will save you some time and
 effort.   If  you have doors and want everyone to be able to play, it
 does  not make sense to have to give everyone the privilege.  Instead
 use these parameters to set the defaults.

      `#DOORPRIVS'        -  Allow new users to have access to doors

      `#ROOMOK'           -   Allow  users  to  be  able to create new
 rooms.

      `#ALLMAIL'          -  Control who can use mail

      `FILE-PRIV-DEFAULT' -   Allow  users  to  have file up/down load
 access
4.5. user characteristics
4.6. #BASEROOM

      Citadels always  have  a  minimum  of three rooms.  There is the
 `Aide  room',  `Mail  room', and the initial room a caller starts out
 in called the base room.

      Historically, the  initial  room  was  always  called The Lobby.
 Most  Citadels  today  have this configuration parameter which allows
 you to name that initial room.

      This parameter  is  a string value obeying formatting directives
 and  goes  through the Citadel formatter, and you must limit yourself
 to  19  characters  or  less  for  this  value.  And one more note --
 Citadel  will  append  the  '>'  to this name when it prints the room
 prompt  for  this  room, you don't have to put it in yourself. If you
 wished to emulate the old CP/M Citadel, you'd set baseRoom thus:

      #BASEROOM "Lobby"

      There is no default for this parameter.
4.7. #MAINFLOOR

      MainFloor is  analogous to #BASEROOM.  Most Citadels have a base
 floor,  just as it has an Aide> room, etc.  This parameter allows you
 to  name  this  base  floor.   This parameter is a string value which
 cannot  be  longer than 19 characters, and specifies the name of your
 base  floor.   So,  if  you  want to name your base floor MAIN FLOOR,
 you'd have

      #MAINFLOOR "MAIN FLOOR"

      There is no default value for this parameter.
4.8. areas

      The BBS  is  organized  into  what  is  called areas.  These are
 directories  that either Citadel creates files in, or uses to recieve
 temporary  files  from  a network session, or user action.  There are
 parameters for each of the major areas.

      `#HOMEAREA'        - The root location of the BBS.

      `#HELPAREA'        - Help files(`.HLP'), menus, and banners

      `#LOGAREA'         - User data files

      `#ROOMAREA'        - Room related files

      `#MSGAREA'         - Message base

      `#FLOORAREA'       - Floor related files

      `#AUDITAREA'       - User, Door, and File activity

      `#HOLDAREA'        - Hold area for user messages

      `#EDIT-AREA'       - Editor area for a sysop editor(console only)

      `#NETAREA'         - Network files area

      `#NET_RECEPT_AREA' - Receiving area for files sent to you

      `#DOMAINAREA'      - Domain data files area

      The `CONFG'  program  will require that you define each area and
 will create the directory if it does not exist.
4.9. #HELPAREA

      This parameter  specifies  where  all of your Help files will be
 located.   These  files  are  *.HLP, *.BLB, and *.MNU.  Normally, you
 should  create  this  directory  and  place  the  help  files  in the
 directory  before  bringing  up  Citadel-86,  since  help  files  are
 usually online at all times.

      #HELPAREA "cit:helps"

      The help   files,   menus  and  default  bulletins  are  in  the
 cithelps.lha  file  in the Citadel Documentation room.  You will have
 to  do  some  customization  of  these files for your system.  If you
 find  an error or re-write the contents of a file, try to return that
 file so that others will benifit from your work.
4.10. #LOGAREA

      This parameter  specifies  the  location  of  your `CTDLLOG.SYS'
 file (this file is sized by your `#LOGSIZE' parameter).

      #LOGAREA "cit:users"         -- put it in a general system dir
4.11. #ROOMAREA

      This parameter   specifies   the   location  of  `CTDLROOM.SYS',
 `CTDLARCH.SYS', and `CTDLDIR.SYS'.

      #ROOMAREA "cit:room"          -- another general system dir
4.12. #MSGAREA

      This parameter  specifies  the location of `CTDLMSG.SYS'.  It is
 also   the   location   of   the   special   Citadel   message   file
 `CIT_MESSAGES.SYS'.   Citadel  will  create the message file when you
 run   `CONFG',  the  other  file  is  supplied  with  the  executable
 archive.

      #MSGAREA "cit:messages"             -- give msgs there own place
 in the sun
4.13. #FLOORAREA

      This parameter specifies the location of `CTDLFLR.SYS'.

      #FLOORAREA "cit:floors"
4.14. #AUDITAREA

      This parameter   is   a  string  value  parameter  specifying  a
 directory  which will hold the audit files.  If this parameter is not
 present  in  your  `CTDLCNFG.SYS' file, then the audit files will not
 be created or updated by Citadel.

      The audit  files  are  usually  text files of information on how
 the  BBS  is  running.   For  example there is a file (`CALLLOG.SYS')
 which  shows information on the callers.  Another file keeps track of
 door  usage  (`DOORUSE.SYS'),  and  another  one the file up/download
 information (`FILELOG.SYS').

      #AUDITAREA "c:audit"         -- This can only be a subdirectory
4.15. CITMESSAGES.SYS

      This file  contains  most  of the Citadel BBS messages.  The BBS
 references  the text via the Message code.  This allows the SYSOP the
 maximum  flexibility  in  configuring  their  BBS.   You  can use the
 standard messages, or customize them to your heart's content.

      The Message  file  is  formatted into one line per message.  The
 first  8  columns may be A "#" for a comment line, or a message code.
 THE  "#"  in  column 1 will cause the rest of the line to be ignored.
 Column  9  is  blank,  for  readability, and columns 10 to 79 are the
 message  text.   If  the message text starts with an "@", the message
 text  is taken to be a filename and that file will be read instead as
 the  message text.  This will allow you to have more than one line in
 a  single  message.   The  message  codes end in either EX for expert
 user  messages,  or  NO  for  novice  user message.  If no EX version
 exists,  the  BBS  will automatically use the NO version.  If neither
 one  exists,  the  BBS  will  display  "***ERROR CODE nnnnnnnn" where
 nnnnnnnn  is  the  missing  message.  If these occur, just create the
 appropriate  message and add it to the file.  If you find any message
 codes in the original file missing, then notify the Amiga Zone.

      One of  the  reasons for the message formatting is to get system
 dependant  information  from the BBS by using special variable names.
 These names are listed below:
   Variable     Description
   ^variant     Name of this Citadel Variant such as "Citadel 68K"
   ^version     Major Version Id of Citadel
   ^sysvers     Minor Version Id of Citadel
   ^baseroom    The baseroom of your BBS
   ^sysop       The name of the Sysop
   ^nodetitle   The BBS Node Title
   ^nodename    The BBS Node Name
   ^nodedomain  The Domain the BBS is considered part of
   ^nodeid      The BBS Node Id
   ^mainfloor   The Floor that contains the BaseRoom
   ^curruser    The name of the Current User.
   ^ulprotocols A list of the Protocols usable for uploading
   ^dlprotocols A list of the Protocols usable for downloading
   ^doorlist    A list of the Doors available in the current room
   ^lastuser    The last caller's name
   ^privileges  A list of the privileges you currently have.
   ^callcount   The number of calls this Citadel has recieved.
   ^ia1         Special Integer Argument #1 (see below)
   ^sa1         Special String Argument  #1
   ^ia2         Special Integer Argument #2
   ^sa2         Special String Argument  #2
   ^ia3         Special Integer Argument #3
   ^sa3         Special String Argument  #3
   ^currtime    The current time
   ^currdate    the current date
   ^s           A single space
   ^n           A newline followed by a space

      The Special  Arguments  are pieces of data that are used in some
 of  the existing messages.  Currently the 3rd one is not used(but may
 be).   Most of the messages do not use them, but those that do should
 probably  continue  to use them.  You can remove the special variable
 from  the  messages  that currently do use them, but adding them to a
 message  that  does  not will get you a zero for an interger argument
 and nothing for a string argument.

      It is  best to keep the original message file around to check to
 see what was available for the code.
4.16. CALLLOG.SYS

      CALLLOG.SYS contains  three  types  of  notes.   The  first type
 lists when the system has come up and down.

      The second  type  records  who  has  called,  listing  login and
 logout times, one line per person, in the following format:

      <person>   :   <login time> - <logout time> <baud rate>

      Occasionally such  a  line will have an extra character appended
 onto it, and they have the following significance.

      '+'  The user logged in as new.

      '-'  The user used .TS to logout.

      'T'  The user timed out on the system.

      'E'  The user hit the error limit on the system and was kicked off.

      'B'  The system kicked the user off for too many offenses against `BADWORDS.SYS'.

      'C'  The user tried to chat with you.

      The third  type  of  message  in CALLLOG.SYS are notes regarding
 network  sessions,  both  normal  and anytime-net.  These record on a
 single  line  the  start  and  end  times  of the net sessions.  This
 particular  message  can  be  disabled  by  using  the #CLEAN-CALLLOG
 parameter.
4.17. FILELOG.SYS

      FILELOG.SYS format   is  somewhat  different.   Generically,  it
 looks like this:

      <user name> @ <baud rate>

      file1 (n  bytes)  <roomname>  <U  or  D> <start to end> <length>
 <protocol>

      [FAILED]

      file2 (n  bytes)  <roomname>  <U  or  D> <start to end> <length>
 <protocol>

      [FAILED]

      This format  keeps  the number of user names down.  "n bytes" is
 the  size  of  the  file.  "roomname" is the room involved.  "U or D"
 refers  to whether the named file was Uploaded or Downloaded.  "start
 to  end" refers to start time and end time of the file session, while
 length  is  the amount of time involved.  Protocol will be one of the
 three  XMODEM,  YMODEM,  or  WXMODEM,  or  an  external  one you have
 setup.   "FAILED"  will  only  appear  on  the  line  if the transfer
 failed.
4.18. DOORUSE.SYS

      DOORUSE.SYS simply  lists who used what doors for what amount of
 time at what time of the day.  It appears in the `#AUDITAREA'.
4.19. #HOLDAREA

      Citadel has  an  optional  capability to save a user's messages,
 put  them  on  hold  so  to speak.  This can be because the user lost
 carrier  while  entering  a  message,  or  told  the  BBS to Hold the
 message  for  later.   The reason this is optional, is that if you do
 not  specify  this  area,  a user will not be able to use this option
 and  any  message  held  will  be  lost  when the user terminates the
 session.   A held file takes about 8K bytes of space on the disk.  It
 is  possible  that  every user could have a held message at one time,
 each  is  uniquely  identified so in figuring disk space, this should
 be remembered.

      #HOLDAREA "hold"
4.20. #EDIT-AREA

      The optional   edit  area  goes  along  with  the  sysop  editor
 directive  `#EDITOR'  which  is  used to define a directory where the
 BBS   will   put  the  temporary  message  file  and  run  the  sysop
 editor(this  is  for  the  console  user only).  This is like any BBS
 area.

      #EDIT-AREA "RAM:"
4.21. #EDITOR

      This is  the  command  that  is used to run the optional Console
 user  editor.   When  a user is logged into the console, this command
 is  used to invoke the external program to edit the message text(will
 be  written  to  tempmsg.sys  in  this  area).   This  command should
 specify  any  options  needed to make the editor run and have the BBS
 pause  while the editor is running(some editors will release the task
 as  soon  as  they  startup  which  will make Citadel think your done
 editing).

      #EDIT-AREA "TTX WAIT"
4.22. #NETAREA

      This command  tells  the  BBS  where  to  put the files that are
 related to the network process.  It is like any other BBS area.

      #NETEAREA "NET"
4.23. #NETRECEPTAREA

      This is  a special BBS directory that is used to store all files
 sent  to  your  system  by  another  system during a network session.
 When  a  system uses the Send File faculty(not the same as requesting
 a file over the network).

      #NET_RECEPT_AREA  "Recieving"

      Files sent  to  your  BBS using the utility `AFF' will appear in
 this   area.    In  addition,  the  parameters  `#NET_AREA_SIZE'  and
 `#MAX_NET_FILE'  will  be  used  to limit the amount of files and the
 largest file in this area.
4.24. #NETAREASIZE

      This parameter  controls  the  total amount of space you wish to
 allow  files  coming into your system via the net(Send File Command).
 This  is  the  limit  on files being sent to your without you asking.
 If  this  area  fills  up  to  this  size,  additional  files will be
 rejected.
4.25. #MAXNETFILE

      This parameter  controls  the size of the largest file your will
 allow  to be sent to you during a network session.  Files larger than
 this size will be rejected.
4.26. #DOMAINAREA

      This parameter  specifies  the  area  where Citadel will put the
 domain   related  temporary  files.   The  files  in  this  area  are
 dynamic.   Citadel  will  create  them  as  needed  and maintain them
 totally.   You  will not need to worry about these files unless there
 is  a  problem  with  domain  mail  and  you  are the server for your
 domain.   This  is  a  fairly  advance  topic and not covered in this
 document.   Eventually,  there  will be a separate document for these
 types of issues.
4.27. basic system parameters

      The basic      system     parameters     define     how     many
 `rooms'(`#MAXROOMS'),  messages  per room(`#MSG-SLOTS'), private mail
 messages    per    user(`#MAIL-SLOTS'),    Size    of   the   message
 base(`#MESSAGEK')  and  if you will want it encrypted (`#CRYPTSEED').
 You  want  to give some careful thought to these parameters since any
 choices  made  now  will be a bit painful to modify later.  There are
 `utilties'  that  will  allow  parameters to be modified, but only to
 increase  them.   To  decrease  them  requires that you start over by
 deleting the appropriate files and reconfiguring.

      I recommend  that  you  keep  `#CRYPTSEED'  at zero although any
 value  can  be  used.   It  makes  debug easier for me if I grab your
 files  plus that value will speed up all the processing.  The message
 slots  and size of the message base is a little cryptic.  If you have
 100  slots,  then Citadel will remember the last 100 messages in each
 room.   Mail has a separate value, but it is the same idea.  With 100
 rooms,  you have 10,000 active messages possible in the system.  With
 messages  sizing  from   500  bytes  to  7500 bytes, you could have a
 message  base  of  5,000,000  to  75,000,000!   Typically the average
 message  is  alot  closer  to the 500 bytes size.  The 600K size here
 gives  me  a  file  that  is 1217 blocks in size(614400 bytes).  This
 would  actually  fit  on  a  floppy  if  you wanted(although it would
 pretty  much  fill  the  floppy).  You can make these pretty much any
 value  you  want,  the  larger  the  value  the  more  the disk space
 needed.  A reasonable approximation for messagek is:

      ( MSG-SLOTS + MAIL-SLOTS ) * 2.75K

      ( 120 + 99 ) * 3K = 602.25

      You can  use  more.....   For  the larger sized system, use 7.5K
 and get 1604K...  The practical limit is 4095K
4.28. #CRYPTSEED

      CRYPTSEED is  a value used in encrypting the data files.  Choose
 a  value  when  you  install the system, but not thereafter -- or you
 won't  be  able  to  read  the existing files any more.  If you use a
 value  of  zero,  none of the data files will be encrypted.  This has
 little  value  since  you  as  SYSOP can access anybody's account and
 read  any message, there is no privacy.  I recommend using zero.  You
 should  not  allow  any of the system files to be downloaded and this
 is  the only protection you have if you do.  It is better to keep the
 users  out  of  the data files.  Using zero has an additional benifit
 that  your  system  will  be  slightly faster.  If you use a non zero
 encryption  seed,  all  the  data files will be encoded.   An example
 is:

      #CRYPTSEED 1234

      It is  important that you do not change this value.  If for some
 reason  you  should  lose  your `CTDLCNFG.SYS' file, run the `VERIFY'
 utility  and  it  will  display not only this value, but the value of
 all  the  important data from this file.  Without this data item, you
 will  not  be  able to reconfigure your BBS.  This is important since
 if  the bbs should crash, or your system should go down while the bbs
 is  running,  you  have to run the CONFG utility to recreate the data
 file  `CTDLTABL.SYS'.   Without  that  file,  the  BBS  will not run.
 There  is  only  one  parameter  on the command line.  If it does not
 match  "onlyParams"  or  "FirstInit"  then  CONFG will assume you are
 re-initializing  the  BBS.   "FirstInit"  assumes  that  you  want to
 create  the  BBS  from  scratch  initializing  all  the  files  as if
 creating  a  new  BBS.   This means that if you already have a BBS up
 and  running,  all  the data files will be re-created and initialized
 as  empty(i.e  all  existing  users deleted, all messages gone).  You
 can  use this the first time and CONFG will not ask you any questions
 about  creating this file or that one...  Once you have a running BBS
 and  you  need  to  modify certain parameters(see `Safe Configuration
 Parameters')
4.29. Safe Configuration Parameters

      These parameters  control  characteristics  of  the  BBS and not
 file  sizes.   You can modify these at any time by changing the value
 in  the  `CTDLCNFG.SYS' file and then running "CONFG ONLYPARAMS".  To
 do  this,  change  the  file,  bring the BBS down, then run CONFG and
 then restart the BBS.
4.30. #NODEID

      As mentioned,  this  parameter  is  a network parameter that has
 traditionally  always  been  set,  even for non-network Citadels.  If
 you  have  no  plans  to ever be on a `C86Net', Then this is not real
 important.

      If you  do  plan  to  join  the `C86Net', (we'll go over this in
 more  detail in the section on `Networking'), then you do have to set
 this parameter correctly.  The format of this parameter is

      "<Country code><Area Code><Phone number>"

      all of  which  applies  to  the  phone  your  system resides on.
 Country  code  is  a  two letter sequence indicating what country you
 live  in (US is the United States, CA is Canada.  Other country codes
 may  be  found  in  COUNTRY.DOC).  Area code is the area code of your
 system  (yes,  we  are  aware  there is a clear bias towards US-style
 telephony).   And  Phone  number is, of course, the phone number your
 system  is  on.   You  can  put  punctuation (such as parenthesis and
 dashes),  but  please  be  conservative with them.  This string value
 does  not  obey  formatting  directives.   Here's  a  fairly  generic
 example:

      #NODEID "US [phone]"   -- Some system somewhere..:)

      Other systems   will   use   your   node  id  to  call  you  for
 networking.   It  will  be  how  other systems identify your system's
 messages.
4.31. #NODENAME

      nodeName is,  in reality, purely a network parameter, and if you
 have  no plans to ever join a `C86Net', then there is no need to fill
 in  this  parameter.   However,  it has always been traditional, even
 before  there  was  a net for any Citadel system anywhere, to fill in
 this  and the `#NODEID' parameter.   nodeName is a string value which
 does  NOT  accept  formatting directives (i.e., formatting directives
 will  be  ignored).   It  can  be no longer than 19 letters long.  It
 should  be  a  short, mnemonic name for your system.  An EXAMPLE of a
 reasonable value:

      #NODENAME "ODD-DATA"             -- The original Citadel

      If you  ever  do  join  a  `C86Net',  messages  from your system
 appearing on another Citadel-86 node will look something like this

      82Nov23 from Cynbe ru Taren @ODD-DATA

      except ODD-DATA   would   be   replaced   with  your  value  for
 #NODENAME.
4.32. #NODETITLE

      The first  parameter  you should find is called nodeTitle. It is
 a  string  value  obeying  formatting  directives,  and is subject to
 formatting   considerations.    nodeTitle   is   the  title  of  your
 installation  printed  when carrier is detected on your system.  More
 precisely,  nodeTitle  will  show  up  in the following place on your
 system:

      Welcome to <#NODETITLE>

      However, nodeTitle  may  not  necessarily  be  printed  at  this
 point.   After  successfully  bringing your system up, please consult
 the  section  on  Help  Files for more information on banner options.
 EXAMPLE:

      #NODETITLE "Test   System\n  Truly  a  Heaven  in  Reverse"  The
 #NODETITLE  is  printed out on .Read Status commands, also.  There is
 no formal limit on the length of this parameter.
4.33. banners
4.34. The Amiga Zone

      The Amiga  Zone is the primary support BBS.  The number is (609)
 953-8159.   There are other Citadels that will help the budding Sysop
 out,  but  this  is  the  place you will find the latest and greatest
 version  of  Citadel,  CONFG,  and  the  Utilities.   In  addition to
 calling  direct,  you  should  think about networking the Citadel 68K
 room.   This  is  the  place  where  comments, bug reports, and other
 issues  are  discussed.   The  Amiga  Zone  will feed the room to any
 Citadel  that  wishes  to  network,  however, the Amiga Zone will not
 call  out for a network session unless the system is local.  You will
 have  to pay for the calls.  This does not amount to much if you call
 a  few  times  a  week.  Fortunately, there are about 200 Citadels in
 the  USA  and  Canada, you might find a local system to network with,
 or  one  that costs less than the Amiga Zone to network with.  If you
 wish,    I   will   answer   questions   at   my   internet   address
 "[e-mail]" or "[e-mail]".
4.35. #LOGSIZE

      This numerical  parameter  gives  you  the ability to decide how
 many  accounts will be available on your system.  If you run a system
 in  which  more  accounts  are used than there are accounts reserved,
 then  new  accounts  are generated by killing old accounts.  Accounts
 are  recycled  by finding the account who's last use is the oldest of
 all  the accounts in the system, under the assumption such an account
 is no longer active.

      All space  is reserved immediately for these accounts.  The size
 of  this  file  can  be  estimated  from  the formula(this includes a
 possible held file for every USER).

      # of  bytes  =  LOGSIZE  *  (82  + MAXROOMS + (6 * MAIL-SLOTS) +
 8092)

      so if  you  are  operating  in  a  restricted  environment, plan
 accordingly.   If  you  need  to,  you can expand the size of the log
 through  the  use  of  the  `DATACHNG' utility, but the log cannot be
 shrunk.  This is a numerical value.  Here is an example:

      #LOGSIZE 200

      For a   system   with   100  rooms(`#MAXROOMS'),  and  100  mail
 slots(`#MAIL-SLOTS')  this  would  be  just  over  150K bytes for 200
 users.   It  should  be noted that the larger the logsize, the longer
 the  `CONFG'  utility  will  take  to  re-configure the system.  Each
 entry is checked and updated when this is done.
4.36. #MAXROOMS

      This numerical  parameter  specifies the maximum number of rooms
 your  system will support.  Since the baseRoom, Aide>, and Mail> room
 are  necessary,  the  smallest  value you can give is 3.  The largest
 number is 65536.  If you wanted to have a 64 room system, you'd have

      #MAXROOMS 64

      You can  use  the  following  formula  to estimate the number of
 bytes a room file will take up on your SYSTEM:

      # of bytes = MAXROOMS *(50 + (6 * MSG-SLOTS))

      For a    system    with    100    rooms    and    200    message
 slots(`#MSG-SLOTS'),  you  would need aproximately 125 Kbytes of disk
 space.   It  should  be noted that the larger this is, the longer the
 `CONFG' takes since each room is updated.
4.37. #MAIL-SLOTS

      This is  a  numerical parameter specifying how many messages per
 log  record you wish to reserve for Mail.  The Mail> room is the only
 room  in the system whose data is not kept in CTDLROOM.SYS.  Instead,
 the  file  CTDLLOG.SYS  contains the "Mail>" room, reserving for each
 account  enough  room  for MAIL-SLOTS Mail messages.  Therefore, this
 parameter  gives  you  the  ability  to  decide the maximum number of
 Mail>  messages  per user they can access.  Please remember if a user
 gets  more  messages  in  Mail> than there are MAIL-SLOTS between two
 successive  logins,  then they will lose the earlier messages sent to
 them.   Another  consideration  is many users like to review old Mail
 when   engaged  in  an  in-depth  private  conversation.   Therefore,
 setting  MAIL-SLOTS  to  a  low  value  may  not  be  the  attractive
 alternative  it  first seems.  However, it should go without saying a
 high  MAIL-SLOTS  value  may  eat up more room than necessary on your
 drives.   The  section  on  `#LOGSIZE' will give an exact formula for
 how much space your log will take up.
4.38. #MESSAGEK

      MESSAGEK defines  how  much  disk space you wish to allocate for
 messages  on  your  installation.  Because messages can vary in size,
 there  is  no  way  to  define how many messages you can have in your
 system,  or  how fast they turnover.  All the messages in your system
 will  reside  in CTDLMSG.SYS, and thus the number of messages in your
 system  at  any given moment will depend totally on the length of the
 messages  being  entered into the system by your users.  The turnover
 rate of your messages will depend on how busy your system is.

      For example,  if  you  reserve 600K for messages, you would have
 an  approximate  1200  messages(messages  can  get  as  large  a 7500
 characters  so  if you have verbose users, this could be as low as 80
 messages  if they were all to the limit, a good conservative estimate
 is  512 characters which gives 1200 messages).  If you get 25 callers
 a  day and each posted 4 messages, you would have a turnover of about
 12  days.   If  you  networking and get 25 messages a day in 4 rooms,
 plus  these  callers,  you  have  a  6  day turnover.  The higher the
 volume,  the quicker the turnover.  When the messages turnover, older
 message  space  gets  reused  which means older messages are deleted.
 Shared rooms can have a very high volume.

      The sysop  of an installation should also keep in mind that very
 large  systems,  with  many  new messages, can be intimidating to new
 users,  so  large  message  spaces should be approached with caution.
 Remember,  there  is  a  utility(`Expand')  for expanding the message
 base,  but not for shrinking it.  The only method available to shrink
 the  message  base  is to delete the existing one and then reset this
 value  to a smaller amount.  You will lose all the messages(including
 mail) if you do this.

      This is  a  numerical  value  which you specify in 'K', which is
 actually  1024  bytes/K.   So, for example, to specify a 250K message
 file

      #MESSAGEK 250               -- 250K message base

      The above parameter will require 250 Kbytes of disk space.
5. Utilities
6. Installation
7. C86Net
8. BBS List
9. Citadel
10. Files
10.1. debug.sys
10.2. crash.sys